Subject: Outstanding issue from AIW 8 - responses due by 9/1/95

From: "Peter W. Gayek" <[email-masked]>
Date: Thu, 24 Aug 95 17:45:38 EDT

For those who may not have been present, the AIW/IETF DLSw MIB working
group met on Tuesday 8/22 at AIW 8 in Raleigh, NC.  Brian Jewell from
3COM was kind enough to take notes for the session and agreed to post
minutes on or before next Friday 9/1.  In the meantime, I agreed to
post a note about the one open issue left from the discussion.  Other
than this issue, the draft 05 MIB was approved with minor modifications
to take forward in the IETF MIB review process.

Please see attachment 1 below for a description of the issue and
options 1 and 2.  A third option (we named it Option 0) emerged in the
discussion - this was to reserve an index value (either 0 or 1) for
row creation, and the DLSw agent would assign an index value of its
own choice once row creation was complete.  This was initially attrac-
tive but has problems if multiple managers are doing simultaneous
row creation, makes it very difficult for the managers to learn the
index value chosen, and has the unseemly quality that a set followed
by a get of the same index value may not yield the same results.  So
Option 0 fell from favor.

The consensus was that Option 2 is the preferred solution, but that it
may require extensions to many products' SNMP "toolkits".  We would
all check to see if these extensions posed too great an implementation
obstacle, and would post any objections to Option 2 by Friday 9/1/95.
As a precedent for a GET operation to cause something other than a
simple retrieval operation, Dave Chen has provided a reference excerpt
in Attachment 2.

If objections are posted, the consensus was that we will pursue Option 1
and make clear any necessary rules about index value assignment to
make that option work.

Thanks,
Peter Gayek

=== Attachment 1 - initial problem statement ======================
Subject:  cache row creates

Here's a new issue to think about and discuss at the AIW next month.
When a mgt station wants to create a cache row entry (e.g.,
configure a local resource), it needs to assign the integer index
value for the new row.  The value chosen could collide with index
values being chosen by DLSw for new dynamic entries.  How do we ensure
this does not happen?

I think it's very desirable for the managed DLSw to control the index
value space.  Option 1 is:
  - mgt station dumps cache and notes current max index value
  - mgt station guesses a safe new index and tries row create
  - DLSw rejects SET if the value collides, and mgt station has to
    try again

An Option 2 Dave Chen suggested is that we expose in two new objects
(one for MAC and one for NB) the next numbers that DLSw is going to
assign.  There can be a convention (I think there is precedent
for this) that if the mgt station GETs that object, we return the
current value and then increment it in one operation.  This would
essentially "reserve" a value for use by the mgt station in a row
create operation.  With this approach, the procedure is:
  - mgt station reads object for table in which row is to be created
  - mgt station does row create using returned value

I hope we can discuss this at the AIW and decide on an approach.
Peter

=== Attachment 2 - precedent ==========================================
Date: 24 August 1995, 15:17:20 EDT
From: David D. Chen             (919)-254-6182 8-444 DCHEN    at RALVM29
To:   PWGAYEK
Subject: SNMP GET Causes Some Operations

One of the cases that I referred to is in "The Simplified
Configuration Model for SNMPv2" (draft-ietf-snmpv2-scm-ds-01.txt)
proposed by Waldbusser/Case/McCloghrie/Rose in 5/95 to simplify
SNMPv2 administrative model.  Although, the whole SNMPv2 is
in flux, no one seems to challenge this kind of operation.

in Page 35/36:

userMaintEntry OBJECT-TYPE
    SYNTAX      UserMaintEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "Entries in this table are created by the agent dynamically
            when processing a getRequest operation, and are deleted
            immediately thereafter.  As such, entries are not accessible
            via other retrieval operations."
    INDEX       { IMPLIED userMaintIndex }
    ::= { userMaintTable 1 }

UserMaintEntry ::=
    SEQUENCE {
        userMaintIndex          OCTET STRING,
        userMaintCreate         OCTET STRING
    }

...

userMaintCreate OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (1|39|55))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "A getRequest operation on this object is used to invoke the
            session creation algorithm.  The retrieved value is either a
            single octet with a non-zero value:

            ...

Thanks.  Dave